html.global_attributes.contenteditable - Add note about white-space style hack of Chrome/Chromium when contenteditable=plaintext-only

[masayuki-nakano]

MDN URL

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/contenteditable

What specific section or headline is this issue about?

"paintext-only" definition in the "Value" section should have a note

What information was incorrect, unhelpful, or incomplete?

Currently, Chrome/Chromium has a hack for white-space style when contenteditable value is plaintext-only. That is, they override the specified (or implicit) white-space style to pre-wrap or pre.
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/css/resolver/style_adjuster.cc;l=405-415;drc=3a3c641c8597f54a4eb6286d816f52b8a649c8bf
And they always use \n as a line break instead of <br> and never use NBSPs when user types white-spaces consecutively.

However, this is invalid behavior from CSS spec point of view and this hack leads different result from Firefox and Safari. Firefox and Safari do not override white-space style and use <br> instead when inserting a line break. And also they use pairs of an NBSP and an ASCII space if multiple collapsible white-spaces are typed consecutively. I.e., these behaviors are same as contenteditable=true if white-space style does not preserve line breaks and/or consecutive white-spaces.

In other words, Chrome/Chromium's hack leads web-compat issue between browsers.

If the web app wants to retrieve the input values of contenteditable=plaintext-only with Element.textContent, the web app should specify white-space: pre or white-space: pre-wrap explicitly. Then, web apps do not need to take care of this incompatibility.

What did you expect to see?

So first, there should be a note that explains what Chrome/Chromium does. Their hack makes web apps access the result with Element.textContent easier, but web apps cannot use white-space: normal, etc for plaintext-only.

And then, recommend to specify white-space style to pre-wrap or pre explicitly.

Do you have any supporting links, references, or citations?

• Chromium's issue: https://issues.chromium.org/issues/413427424
• Invalid bug reports to Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1950671 and https://bugzilla.mozilla.org/show_bug.cgi?id=1962439
• Invalid bug report to Safari: https://bugs.webkit.org/show_bug.cgi?id=288517

Do you have anything more you want to share?

Nothing special.

MDN metadata

Page report details

• Folder: en-us/web/html/reference/global_attributes/contenteditable
• MDN URL: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/contenteditable
• GitHub URL: https://github.com/mdn/content/blob/main/files/en-us/web/html/reference/global_attributes/contenteditable/index.md
• Last commit: mdn/content@5a19517
• Document last modified: 2025-04-11T18:00:00.000Z

[caugner]

This sounds like we should add notes for this feature's Chrome entry in BCD:

browser-compat-data/html/global_attributes.json

Lines 350 to 352 in af207da

	"chrome": {
	"version_added": "51"
	},

[caugner]

@masayuki-nakano Thanks for reporting. Would you like to open a PR adding notes to that Chrome support statement, explalining how white-space styles are replaced with this feature?

browser-compat-data/html/global_attributes.json

Lines 350 to 352 in af207da

	"chrome": {
	"version_added": "51"
	},

(Chromium source code: https://github.com/chromium/chromium/blob/b2acd809f4b4d12c23b9726ccb223d8b8e62baba/third_party/blink/renderer/core/css/resolver/style_adjuster.cc#L408-L415)

[masayuki-nakano]

Unfortunately, I don't have much time for several weeks, once nobody can do that, I'd try...